comments

diff --git a/doc/bugs/35_failed_tests_on_beegfs/comment_1_07b18e92f2abc25c5666f4ca83bbe1cd._comment b/doc/bugs/35_failed_tests_on_beegfs/comment_1_07b18e92f2abc25c5666f4ca83bbe1cd._comment
new file mode 100644 (file)
index 0000000..8f27e55
--- /dev/null
+++ b/doc/bugs/35_failed_tests_on_beegfs/comment_1_07b18e92f2abc25c5666f4ca83bbe1cd._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-08-29T15:16:00Z"
+ content="""
+The failures are mostly of two varieties.
+
+type A:
+
+      add:                            FAIL (2.20s)
+        ./Test/Framework.hs:395:
+        checkcontent foo
+        expected: "annexed file content"
+         but got: "could not read file"
+
+type B:
+
+      init:              OK (1.98s)
+      add:               FAIL (5.90s)
+        ./Test/Framework.hs:92:
+        unlock failed with unexpected exit code (transcript follows)
+       unlock sha1foo cp: cannot open '.git/annex/objects/3j/xV/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa' for reading: No such file or directory
+
+In both cases, a `git-annex add` is succeeding, but the annex objects
+directory is somehow not getting populated. Or at least, a subsequent read
+of a file in it has the filesystem not knowing the file that the add put
+there is there.
+
+It seems quite likely a lot of other tests would also fail, but they are being
+skipped because the add tests fail.
+
+In one case, the add tests are succeeding (on an adjusted unlocked branch), 
+but then a subsequent test fails:
+
+    git-remote-annex exporttree:      FAIL (8.45s)
+      ./Test/Framework.hs:92:
+      export failed with unexpected exit code (transcript follows)
+      mv: cannot move '.git/annex/othertmp/89ddefa4-a04c-11.0/89ddefa4-a04c-11' to '.git/annex/export.ex/89ddefa4-a04c-11ef-818d8a-1-c6223d6': Device or resource busy
+      mv: cannot move '.git/annex/othertmp/89ddefa4-a04c-11.0/89ddefa4-a04c-11' to '.git/annex/export.ex/89ddefa4-a04c-11ef-818d8a-2-c718026': Device or resource busy
+      git-annex: renamePath:rename '.git/annex/othertmp/89ddefa4-a04c-11.0/89ddefa4-a04c-11' to '.git/annex/export.ex/89ddefa4-a04c-11ef-87b5-e880882a4f98': resource busy (Device or resource busy)
+"""]]

diff --git a/doc/bugs/35_failed_tests_on_beegfs/comment_2_0d3117fc63c4d360423fbf834a0e7d8d._comment b/doc/bugs/35_failed_tests_on_beegfs/comment_2_0d3117fc63c4d360423fbf834a0e7d8d._comment
new file mode 100644 (file)
index 0000000..cb09384
--- /dev/null
+++ b/doc/bugs/35_failed_tests_on_beegfs/comment_2_0d3117fc63c4d360423fbf834a0e7d8d._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-08-29T15:31:42Z"
+ content="""
+I'm not familiar with beegfs, but its documentation such as this
+<https://doc.beegfs.io/latest/architecture/overview.html> makes me wonder if it
+manages to behave consistently as we would expect a filesystem to behave.
+
+In particular, we have a file being moved from one directory to another
+directory. Beegfs's docs says it will pick a random metadata node for each
+directory. So there can be two metadata nodes that have to be updated for a
+move. If one node somehow lags seeing the update, could that result in the file
+not appearing as present in the destination directory after the move?
+
+I'm only speculating about how beegfs might work, but it seems unlikely that
+git-annex has a bug that causes it to lose an annexed file when all it's done is
+move it to the objects directory, that only manifests on this one filesystem.
+
+A good next step might be to try manually adding an annexed file and see
+if there is some lag between `git-annex add` and being able to read the content
+of the symlink. Eg, compare:
+
+       echo foo > foo
+       git-annex add foo; cat foo
+       echo bar > bar
+       git-annex add bar; sleep 1m; cat bar
+"""]]